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1 

MESSAGING PLATFORM 

The present invention relates to a messaging platform suitable for use in a 
communications network. 
5 Users of communications networks are now commonly offered a variety of 

messaging services. By contrast with conventional telephony services in which 
calls are established in real time, in messaging services a message, which may be 
in any of a number of media, is deposited at one time and read at a later time. 
These services may include, for example, voicemail allowing the user to record a 
10 spoken message, faxmail that similarly allows a fax to be stored for later retrieval 
by the addressee, or email 

According to a first aspect of the present invention, there is provided a 
messaging platform including 

a) a message store arranged to receive message data and to store said 
15 message data for subsequent retrieval, 

characterised by 

b) an overload controller responsive to an overload condition in the 
platform and arranged, in response to the said overload condition, to limit loading 
of the platform 

20 While it is known to provide platforms for real-time telephony with 

overload control mechanisms, conventionally messaging platforms have been 
regarded as carrying out an "off-line" data storage and processing function and so 
have not included such overload control mechanisms. The present inventors have 
found however that the addition of an overload controller to a messaging platform 

25 significantly enhances the stability and scaleability of the platform, that is to say 
its ability to adapt to increasing numbers of users. 

The term "overload condition" as used in this document encompasses 
conditions in which the loading of the platform is approaching a level at which the 
operation of the platform would be impaired, as well as conditions in which such a 

30 level has already been reached. In general the overload controller will be arranged 
to limit the loading of the platform is such a way that the level at which 
impairment occurs is not reached. 

Preferably the platform further comprises 
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c) a control interface arranged to receive control requests instructing transactions 
on the messaging platform, and the overload controller includes means for denying 
at least some of the control requests in response to the overload condition. 

While at one time the messaging platforms supporting such services were 
5 operated solely under the control of the network operator, increasingly messaging 
services are operated by service providers other than the network operator. 
Accordingly it is necessary to provide the messaging platform with a control 
interface to allow communication of control signals with the service provider. In 
addition, in order to implement more advanced services which go beyond mere 
10 message deposit and retrieval, it necessary to provide users with some, access to a 
control interface. The present inventors have recognised that overloading of the 
control interfaces .on a messaging platform is a critical factor in degrading the 
reliability of such platforms. This preferred feature of the invention, by providing 
an overload controller on the control interface significantly enhances the 
15 performance of the platform and makes it possible to open control interfaces to 
service providers or to users without compromising the stability of the platform. 

Preferably the overload controller includes a store programmed with 
criteria for applying different classes of service to (a) the mailboxes in the mail 
' store, (b) the service providers accessing the mail store, (c) control messages at 
20 the control interface, or any combination of these. The overload controller is 
arranged, in response to an overload condition on the platform or the service 
provider, selectively to deny access to a control message depending on a class of 
service assigned in accordance with the said criteria to the control message. 

Preferably the messaging platform includes a plurality of mailboxes 
25 containing message data, each mailbox being switchable between an open state, in 
which message data may be written to or read from the mailbox, and a closed 
state, and the overload controller is arranged to allow requests for the closing of a 
mailbox and to deny requests for the opening of the mailbox. 

The inventors have found that a particularly effective means of limiting the 
30 loading of the platform, while also limiting the impact on ongoing transactions, is 
to admit requests for closing mailboxes and to deny requests for opening 
mailboxes. Since requests for opening mailboxes are normally followed by a 
number of related transactions, denying these requests, while allowing existing 
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transaction sequences to be terminated by the closing of a mailbox, quickly results 
in a reduction in the loading of the platform. 

According to a second aspect of the present invention, there is provided a 
messaging system comprising: 
5 a service platform running a messaging service application; and 

a messaging platform in accordance with the first aspect connected to the 
service platform via a control interface, and arranged to receive control requests 
from the service platform via the control interface. 

The service platform may be integrated with the messaging platform, but 
10 preferably is remote from it. Several such service platforms may communicate with 
a single messaging platform. 

According to a third aspect of the present invention, there is provided a 
method of operating a messaging platform including: 

a) storing message data on the messaging platform: 
15 b) subsequently outputting message data from the platform, thereby 

allowing retrieval of a corresponding message; 
characterised by 

c) detecting an overload condition on the platform and in response to the 
overload condition limiting loading of the platform. 
20 Systems embodying the present invention will now be described in further 

detail, by way of example only, with reference to the accompanying drawings, in 
which; 

Figure 1 is a schematic of a network Incorporating a messaging platform; 
Figure 2 is a schematic of a platform embodying the invention for use in 
25 the network of Figure 1 ; 

Figures 3a to 3y are SDL diagrams showing in further detail the platform 
of Figure 2; and 

Figure 4 is a diagram showing in further detail the platform of Figure 2. 

As shown in Figure 1, a communications system includes a messaging 
30 platform T; The messaging platform 1 is connected to a service provider platform 
2. The service provider platform is connected to a number of communications 
networks including an IP (internet protocol) network 3 and the PSTN (public 
switched telephone network) 4. Customer terminals 5,6,7 are connected to the 
service provider platform variously via the PSTN and via the IP network. The 
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customer terminals may include for example, conventional fixed-tine telephones, 
mobile telephones and also personal computers. 

In use, customers may subscribe to a message service offered by the 
service provider. Then, for example, when a subscriber is not able to take a call 
5 from a calling party, the call may be diverted to the service provider platform. The 
service provider platform may then communicate data received from the caller, for 
example in the form of a recorded digitised voice message, to the messaging 
platform. 

Figure 2 shows in further detail the messaging platform. This may be 

10 implemented, for example, using the BT CallMinder platform (described in (British 
Telecom Engineering Vol 15 Part 2 July 1996]), which is based on the Speech 
Applications Platform (described in [British Telecom Engineering Vol 13 Part 4 
January 1995]). The CallMinder platform Is an integrated platform implementing 
both a service application platform and the messaging platform. Alternatively a 

15 distributed architecture may be used in which a number of service provider 
platforms communicate with a message platform over a network. In this case, a 
suitable architecture is that described in Messaging APIs for Voice Networks, RM 
Claxton. Sixth lEE Conference on Telecommunications (no. 451) 1998. 

As shown in Figure 2, a number of service providers, A,B m are 

20 connected to the messaging platform by control and data channels. As noted in 
the introduction above, some end users may themselves be given access to the 
control interface of the messaging platform, and the term "service provider" is 
used here broadly to encompass any party accessing the control interface, 
including such end users. The control channels are used for registration 

25 commands, for example to set event detection triggers on the platform to generate 
a notification whenever a message is left for a specified subscriber, and for action 
commands, for example to carry out actions such as replaying a message, saving a 
message or deleting a message. Both data and control channels from the service 
providers pass in the first instance to an access controller. The access controller is 

30 connected to an overload controller. The overload controller and access controller 
in combination function to protect the platform from overloading by signals arriving 
on the service provider interface. The overload controller detects overload 
conditions, for example by monitoring the rate of transactions between the access 
controller and service providers or alternatively by monitoring the processor 
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utilisation of the mail store processors. When an overload condition is detected by 
the overload controller then the overload controller configures the access controller 
to deny access to the platform to certain signals (for example, requests to open a 
low priority mailbox in the mail store). Different types of signals are assigned 
5 different priorities. Three alternative schemes are described below by way of 
example. 
Scheme 1 

in this scheme, different service classes are applied to different service 
providers. During overload conditions, as monitored by a load controller, those 

10 subscribing to a higher priority class of service level agreement are given priority 
over those requests coming from a Service Provider with a lower priority class. 
Hence, actions pertaining to the particular mailboxes used by customers of the 
higher priority class of service would receive preferential treatment. It is envisaged 
that a range of service classes will be defined, which will correspond to the 

15 overload mechanism achieving a specified quality of service for those classes. 
Examples of service classes are given in Table 1 below. 



Service 
Class 


Description 


III 


Guaranteed end user access 99.99% of the time 

Guaranteed Service Provider notifications within 30 seconds, 

99.99% of the time 


II 


Guaranteed end user access 98.0 % of the time 

Guaranteed Service Provider notifications within 30 seconds, 

90.0% of the time 

Guaranteed Service Provider notifications within 20 minutes, 
99.99% of the time 


1 


No guaranteed end user access 

No guaranteed Service Provider notifications 



Scheme 2 



As in scheme 1 different service classes are used. In this case the different 
20 service classes are applied to individual mailboxes for particular subscribers. 
Mailbox subscribers subscribing to higher service level classes are given priority 
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over requests for action associated with individual mailbox users with a lower 
priority class. 

Schenne 3 

5 In this scheme, different priorities are applied to certain types of transaction across 
the service provider interface. For exanriple, the ability to deposit a message from a 
caller into a mailbox could take priority over a change of profile request from the 
user depending upon the load conditions prevailing. 

As a further alternative, elements of two or more of these schemes may 

10 be combined, so that the priority given to a certain signal at the service provider 
interface may depend upon a weighted combination of the service provider class, 
the subscriber class and the signalling type priority. 

A service provider application which itself becomes overloaded may also 
request that the mail system imposes an overload control scheme (such as those 

15 described above) to protect that application from overload. 

In operation, which ever scheme is used, the overload controller monitors 
an appropriate one or more loading parameters. In the present example this 
parameter Is the rate of transactions between the service provider applications and 
the mailboxes which pass through the access controller. This mechanism provides 

20 a measure of mail system processing usage. Other examples of measuring 
processing load may be based on directly measuring the load on the platform 
Central Processor Units and other hardware devices (this information is usually 
available from operating systems). Alternatively, other load measures, such as the 
amount of storage utilised (disk and memory) can be measured. Again this 

25 information is provided by most operating systems (e.g. Windows 95 and UNIX 
both provide system information). Threshold levels for system loading are defined 
for the mail system. The thresholds are defined such that a defined quality of 
service can be met for particular service classes (seeTable 1), and are dependent 
upon the platform and Mail system being used, and the customer/service mix for 

30 the particular implementation. As these threshold levels are reached, the overload 
control management imposes overload control. The following controls can be 
imposed: 

• refusing new requests by Service Providers to open low priority mailboxes, 

• closing Service Provider access to low priority open mailboxes, 
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• refusing end user access to low priority nnailboxes, 

• queuing control messages and data transfers on the next highest priority open 
nnailboxes. 

If the next load threshold level is reached, the same overload controls will be 
5 innposed on the next highest priority mailboxes. If instead, the system load 

reduces, the overload controls set at that level are removed in reverse order to that 

in which they were applied. 

In addition to responding to overload conditions within the platform, the 

overload controller may also be programmed to recognise and respond to signals 
10 from a service platform indicating that that platform is overloaded. The overload 

controller might then, for example, inhibit the transmission of notifications from the 

messaging platform to the overloaded service platform. 

Figures 3a to 3y are SDL (Specification and Description Language 

[ITU-T 2.1001) diagrams showing in further detail the implementation of the 
15 messaging platform, including the overload controller. The structures shown may 

be compiled using commercially available software tools to provide code for 

running on the processors of the messaging platform. A description of the SDL 

diagrams follows: 

20 Figure 3a; Diagram Structure 

Describes the structure of the following figures 3b to 3y. 

Figures 3b-3d: System mail system 1-3 

Defines the static limits of the described mail system, and type definitions and 
25 operators for variables used. 

Figure 3e: System mail system 4 

Defines all of the control signals used in the mail system. 

30 Figure 3f : System mail system 5 

Defines the two main blocks of the system: the mail application block (i.e. the 
service provider platform) and the mail system block (i.e. the messaging platform). 
The interfaces between the blocks (the mail system API), and to/from the external 
environment are also defined. 
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Figure 3g: Block mail application block 1 

Defines the processes and interfaces within the mail application block. In this case, 
only the mail application processes are defined. 

5 

Figure Sh-Sj; Process mail application 1-3 

Defines all of the control signals, variables, states, states transitions and actions of 
the mail application necessary to illustrate the present invention. The process 
contains one state ('alive'), and acts on a number of events as follows: 

10 user mailbox _open: A request from a user (or some other stimulus) to open a 
mailbox results in a request to the access controller to open a mailbox. 
user jnailbox close: A request from a user (or some other stimulus) to close a 
mailbox results in a request to the access controller to close a mailbox. 
user mailbox request: A request from a user |or some other stimulus) to perform 

15 an action on an open mailbox usually results in a request to the access controller 
to perform an action on an open mailbox. If however, the mail system is 
overloaded, then the request will be queued. 

mail ^application overload jdetected: An indication from the service provider 
platform (or some other stimulus) that the mail application is overloaded results in 
20 a request to the access controller to impose overload controls on open mailboxes 
opened by that application that are below a specified service class. Requests to 
these mailboxes are not queued. 

mail applicatior} overload ceased: An indication from the service provider platform 
(or some other stimulus) that the mail application overload has ceased results in a 
25 request to the access controller to remove overload controls on open mailboxes 
opened by that application that are above a specified service class. 
UM opened: Confirms that a mailbox has been opened. 
UM closed: Confirms that a mailbox has been closed. 

UM open denied: Indicates that a request to open a mailbox has been denied - for 
30 example because overload controls have been imposed. 

UM notification: Indicates a notification from a mailbox, which is passed back to 
the application user (if appropriate). The notification could be the result of an 
earlier mail application request on the mailbox, or another (e.g. timer) event. 
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queue UMjequests: Indicates that the access controller has imposed overload 
controls on a mailbox, and that the malt application should not make further 
requests on that mailbox. The mail application will queue subsequent requests. 
resumeJUM requests: Indicates that the access controller has removed overload 
5 controls on a mailbox, and that the mail application can make further requests on 
that mailbox. Any pending requests in the queue will be immediately sent to the 
mail system. 

Figure 3k: Block mail system block 1 
10 Defines the processes and interfaces within the mail system block. In this case, 
there are three processes: the single access controller, the single overload 
controller, and the multiple user mailboxes. 

Figure 3l-3p: Process access controller 1-5 

15 Defines all of the control signals, variables, procedures, states, states transitions 
and actions of the access controller necessary to illustrate the present invention. 
The process contains one state ('alive') that is entered after the 'tr_timer' has been 
set. The process acts on a number of events as follows: 

UM open: A request from a mail application to open a mailbox is received. The 
20 transaction counter is incremented. If the mailbox has a higher priority ('class') 
, than that set by the overload control mechanism, the mailbox is opened (by 

creating a user mailbox process), the identity of the mailbox is added to the linked 
list of open mailboxes, and the actions are confirmed to the mail application. 
Otherwise, the mail application is informed that the request is denied. 
25 UM dose: A request from a mail application to close a mailbox is received. The 
transaction counter is incremented. The mailbox is. closed - by terminating the user 
mailbox process, the identity of the mailbox is removed from the linked list of open 
mailboxes, and the actions are confirmed to the mail application. 
UM request: A request from a mail application to perform an operation on an open 
30 mailbox is received. The transaction counter is incremented. If the overload control 
is not applied to that mailbox, then the request is passed onto the mailbox. 
Otherwise, the request is placed in an request queue. 

set UM_class bar: A request from the overload controller to set the priority level 
('class') at which mailboxes may be opened or controlled is received. If the priority 
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level is higher than the current priority level Ithe 'current_class_bar'), then mail 
applications with open nnailboxes below the priority level are requested to queue 
further requests to that mailbox (procedure 'queue_transactions'), the current 
priority level is raised to the new level. If the priority level is lower than the current 
5 priority level (the 'current_class_bar'), then any queued requests received from mail 
applications are unqueued (procedure 'unqueue_requests'|. Following this, mail 
applications with open mailboxes above the priority level are requested to resume 
further requests to that mailbox (procedure 'resume_transactions'), and the current 
priority level is lowered to the new level. 
10 notification: A notification from an open mailbox is received. The transaction 
counter is incremented, and the notification is passed on to the relevant mail 
application. 

impose JJM had controi: A request from a mail application to impose load control 
on open mailboxes that were opened by the application is received. Mailboxes with 

15 a class less than or equal to the specified level are requested to queue up 
notifications, if not already doing so. Mailboxes with a class greater than the 
specified level are requested to resume notifications, if not already asked to do so. 
This mechanism does not override any controls imposed by the overload controller. 
trjimer: A transaction timer expiry event is received. The transaction timer Is set 

20 to expire every second. The current transaction rate is thus the value of the 
transaction counter, per second. This overload controller is informed of the current 
transaction rate, the transaction counter is reset to zero and the tr_timer reset. 

Figure 3q: Procedure get UM class 1 
25 Defines the procedure for retrieving the provisioned service class of a mailbox from 
the management system for the mail system. 

Figure 3r: Procedure queue transactions 1 

Defines the procedure for informing the mail application to queue requests to open 
30 mailboxes, and informing the mailbox to queue notifications, when overload 
controls are imposed. 
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Figure 3s: Procedure resume transactions 1 

Defines the procedure for informing the mail application to queue requests to open 
mailboxes, and informing the mailbox to queue notifications, when overload 
5 controls are imposed. 

Figure 3t: Procedure unqueue requests 1 

Defines the procedure for unqueueing requests for operations on mailboxes when 
overload controls have been removed. 



Figure 3u: Process overload controller 1 

Defines all of the control signals, variables, procedures, states, states transitions 
and actions of the overload controller necessary to illustrate the present invention. 
The process contains one state I'monitoring') that is entered after the threshold 
15 levels for the overload controls have been set in the threshold levels table. The 
process acts on a number of events as follows; 

transaction rate: An indication of the current transaction rate at the access 
controller is received. If this rate has fallen below the current minimum level, then 
the current overload priority rUM_class_bar') is decremented (if it is not already at 

20 the lowest level). The threshold levels are then adjusted accordingly - from the 
threshold table, and the access control is requested to reduce or remove the 
overload control. If, alternatively, the rate has risen above the current maximum 
level, then the current overload priority ['UM_cIass_bar') is incremented (if it is not 
already at the highest level). The threshold levels are then adjusted accordingly and 

25 the access control is requested to increase the level of overload control. 



Figure 3v: Procedure set thresholds 1 

Defines the procedure for setting the threshold levels in the overload control 
threshold table. These levels define the points at which the oveload controls will 
30 be imposed or removed. 
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Figure 3w-3x: Process user mailbox 1-2 

Defines all of the control signals, variables, procedures, states, states transitions 
and actions of the user mailbox necessary to illustrate the present invention. The 
process contains one state ('alive'), and acts on a number of events as follows: 

5 queue notifications: An request to queue notifications is received from the access 
controller. A flag is set indicate that future notifications should be queued. 
resume notifications: An request to resume notifications is received from the 
access controller. A flag is cleared indicate that future notifications should no 
longer be queued, and any queued notifications are unqueued. 

10 request: An request to perform an operation is received from the mail application 
via the access controller. The operation is performed as requested (procedure 
'perform_request'). 

event: An indication that an event has occurred in the mailbox (e.g. the result of 
an operation or a timer expiry) is received. If overload control has been imposed, 
15 then the notification of the event to the mail application is queued. Otherwise, the 
notification is sent to the mail application via the access controller. 
stop maiibox: An request to stop the user mailbox process is received from the 
access controller. The user mailbox process terminates, closing the mailbox. 

20 Figure 3y: Procedure perform request 1 

Defines the procedure for the mailbox to perform an operation requested by the 
mail application. 

Figure 4 illustrates an example of hardware systems used to implement 
25 the present invention. It will be understood that the components and architecture 
shown here are given by way of example only, and many alternative components 
and architectures may be used equivalently. For example, rather than using 
platforms built from rack-mounted processors and storage devices, some or ail of 
the platforms might be implemented on computer workstations. Such 
30 workstations may be joined together by a network to provide a distributed 
computing system. As a further example of the alternatives available, storage 
devices are by no means limited to conventional hard disks, but might alternatively 
or in addition use magneto-optical or optical storage media. Also, as previously 
stated, one or more of the "service platforms" may be embodied in a customer 
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terminal that exercises a control function, for exannple in a personal computer, or in 
a so-called internet appliance such as a television set-top box arranged to provide 
Internet access, or in an intelligent telephone that provides the necessary control 
capabilities. 

; 5 In Figure 4, end users connect to the Service Provider platform by 

telephone or computer. One or more Service Provider platforms are connected to 
the Mail Store platform. The Service Provider platform runs the mail applications 
(for example to collect messages, and permit retrieval of messages), interfaces to 
the end users, and sends control and data signals to the Mail Store platform. to 
10 store and retrieve messages held in electronic format. 

It is possible that the Service Provider platform and Mail Store Platform 
reside on the same computing node. In this case the buses B1 and B2 can be 
joined directly, therefore removing the need for interface 13, the Mail Store 
interface shelf (S3) and the Service Provider interface shelf {M3I. Alternatively the 
15 platforms may be connected to each other via a network, for example the Internet, 
an ATM network, or a local area network LAN. 

A description of the system follows: 

20 Interfaces 

Interface II: This is a standard telephony interface, which allows end users to 
record or retrieve voice messages. The interface will usually be provided via a 
telephony network. 

25 Interface 12: This is an electronic data interface to a computer (e.g. TCP/IP), which 
allows end users to record or retrieve voice or electronic messages. The interface 
will usually be provided via a data network such as the internet. 

Interface 13: This is an electronic data interface which transports the control and 
30 data signals between the Service Provider and Mail Store platforms. This is 
typically implemented as an ethernet, frame-relay or X.25 data Imk, running the 
TCP/IP protocol. Control and Data messages may be carried using suitable 
protocols, such as the Internet File Transfer Protocol (FTP). 
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interface 14: This is an electronic data interface to the Service Provider platform 
management system (for example, a customer management system or simply a 
computer terminal). The protocol used with this interface will typicaily be the 
internet Simple Network Management Protocol (SNMP) running over TCP/IP. 

5 

Interface 15: This is an electronic data interface to the Mail Store platform 
management system (for example, a network management system or simply a 
. computer terminal). The protocol used with this interface will typically be the 
internet Simple Network Management Protocol (SNMP) running over TCP/IP. 

10 

Interface 16: This is an electronic data interface which transports the control and 
data signals between the Mail Store platforms. This allows the Mail System to be 
distributed across a number of sites (e.g. for resilience and performance reasons). 
This is typically implemented as a frame-relay or X.25 data link, running the TCP/IP 
15 protocol. Control and Data messages may be carried using suitable protocols, such 
as the Internet File Transfer Protocol (FTP). 

Service Provider Platform Components 

20 The Service Provider platform comprises a number of shelves, which are 
specialised to meet particular needs, and a bus (bus B1) that connects the shelves. 
A shelf is either a processor shelf (consisting of processor, memory, clocks, I/O 
devices, etc.) or a storage shelf (consisting of hard disk storage, disk controllers, 
etc.). 

25 

Shelf SI: Mail Applications Processor shelf. 

This runs the various applications that interface the end users and other 
applications to the mail system. 

30 Shelf S2: Platform Management Processor shelf. 

This runs the necessary management applications for the service provider platform, 
and interfaces to an external management system via 14. 

Shelf S3: Mail System Interface Processor shelf. 



•14 
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This provides the physical termination of the interface (13) to the Mail System 
platform, and runs the software to interface the protocols to the rest of the 
Service Provider platform. 

5 Shelf S4: Interactive Voice Response Processor shelf. 

This runs the software that interacts directly with end uses, usually over the 
telephony interface (II) via the Telephony Interface processor shelf (although it can 
be used to interact with users over the internet interface). This shelf is able to play 
announcements to end users, and record voice messages into electronic format 
10 (e.g. PC '.wav' format), that will ultimately be stored in the Mail System. 

Shelf S5: Telephony Processor shelf. 

This provides the physical termination of the interface (II) to the telephony 
network, and runs the software to interface the protocols and bearer circuits to the 
1 5 rest of the Service Provider platform. 

Shelf S6: Internet Processor shelf. 

This provides the physical termination of the interface (12) to the internet network, 
and runs the software to interface the control and data protocols to the rest of the 
20 Service Provider platform. 

Shelf S7: Runtime Data Storage shelf.' 

Provides hard disk storage for the various processor shelves to use at run time. 

25 Shelf S8: Audit Data Storage shelf. 

Provides resilient hard disk storage for system data that needs to be held for 
logging and auditing purposes. This is usually stored by the processor shelves, and 
retrieved by the external management system via the Platform Management 
processor shelf (S2). 

30 

Mail Store Platform Components 

The Mail Store platform comprises a number of shelves, which are specialised to 
meet particular needs, and a bus (bus B2) that connects the shelves. A shelf is 
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either a processor shelf (consisting of processor, mennorv, clocks, I/O devices, etc) 
or a storage shelf (consisting of hard (disk) storage, disk controllers, etc). 

Shelf Ml: Mailbox Controllers Processor shelf. 
5 This runs the software used to store and retrieve messages and other information 
in user mailboxes. 

Shelf M2: Platform Management Processor shelf. 

This runs the necessary management applications for the service provider platform, 
10 and interfaces to an external management system via 15. 

Shelf M3: Service Provider Interface Processor shelf. 

This provides the physical termination of the interface (13) from one or more 
Service Provider platforms, and runs the software to interface the protocols to the 
15 rest of the Mail System platform. 

Shelf M4 Access and Overload Controller Processor shelf. 

This runs the access controller and overload controller process software for the 
Mail System. 

20 

Shelf M5: Mail System Interface Processor shelf. 

This provides the physical termination of the interface (16) from one or more other 
Mail System platforms, and runs the software to interface the protocols to the rest 
of the Mail System platform. 

25 

Shelf M7: Mailbox Data Storage shelf. 

Provides resilient hard disk storage for the user mailboxes. This is shelf is usually 
only accessed by the Mailbox Controllers shelf (Ml) and the Platform Management 
processor shelf (M2). 

30 

Shelf M7: Runtime Data Storage shelf. 

Provides hard disk storage for the various processor shelves to use at run time. 
Shelf M8: Audit Data Storage shelf. 
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Provides resilient hard disk storage for system data that needs to be held for 
logging and auditing purposes. This is usually stored by the processor shelves, and 
retrieved by the external management system via the Platform Management 
processor shelf (M2). 
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CLAIMS 



1. A messaging platform including: 

a) a message store arranged to receive message data and to store said 
5 message data for subsequent retrieval, 

characterised by 

b) an overload controller responsive to an overload condition in the 
platform and arranged, in response to the said overload condition, to limit loading 
of the platform. 

10 

2. A messaging platform according to claim 1, further comprising: 

c) a control interface arranged to receive control requests instructing 
transactions on the messaging platform, 

and in which the overload controller includes means for denying at least 
1 5 some of the control requests in response to the overload condition. 

3. A platform according to claim 2, in which the overload controller is 
programmed with criteria for applying different classes of service to control 
requests received at the control interface and the overload controller is arranged, in 

20 response to an overload condition on the platform, selectively to deny control 
requests depending on a class of service assigned in accordance with the said 
criteria to the control request. 

4. A platform according to claim 3, in which the criteria apply a class of service 
25 selected depending on the identity of a service provider originating the said control 

requests 

5. A platform according to claim 3 or 4 in which the criteria apply a class of 
service selected depending on the identity of a subscriber mailbox to which the 

30 control request applies 

6. A platform according to any one of claims 3 to 5, in which the criteria apply 
different service classes depending on the transaction requested by the control 
request. 
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7. A messaging system comprising: 

a service platform running a messaging service application; and 
a messaging platform according to any one of the proceeding claims 
5 connected to the service platform via a control interface, and arranged to receive 
control requests from the service platform via the control interface. 

8. A messaging system according to claim 7, in which the service platform is 
remote from the messaging platform. 



9. A communications network including a messaging platform according to any 
one of claims 1 to 6, or a messaging system according to claim 7 or 8. 

10. A method of operating a messaging platform including: 



b) subsequently outputting message data from the platform, thereby 
allowing retrieval of a corresponding message; 

characterised by 

c) detecting an overload condition on the platform and in response to the 
20 overload condition limiting loading of the platform. 

1 1. A method according to claim 10, further comprising 

d) receiving at the message platform control requests instructing a 
transaction on the messaging platform, 

25 and in which the step of limiting loading of the platform includes denying 

at least some of the control requests. 

12. A method according to claim 11, including applying different classes of 
service to the control requests, and in response to the overload condition 

30 selectively denying some only of the control requests depending on the class of 
service applied to the control requests. 



10 
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a) storing message data on the messaging platform: 
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13. A method according to claim 12, including applying different classes of 
service to control requests depending on the identity of an originating service 
provider. 

5 14. A method according to claim 12 or 13, including applying different classes of 
service to control requests depending on identities of customer mailboxes to 
which the control requests apply. 

15. A method according to claim 12, 13 or 14, including applying different 
10 classes of service to control requests depending on the transaction requested by 

the control request 

16. A method according to claim 15, in which the messaging platform includes a 
plurality of mailboxes containing message data, each mailbox being switchable 

15 between an open state, in which message data may be written to or read from the 
mailbox, and a closed state, and in which the step of limiting loading includes 
allowing requests for the closing of a mailbox and denying requests for the opening 
of a mailbox. 

20 
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ABSTRACT 



A messaging platform, for example a platform storing email or voicemail, is 
5 provided with an overload controller which detects an overload condition and then 
acts to limit the loading of the platform. The overload controller may be 
associated with a control interface used, for example, for communication between 
a service provider and the message platform, and may selectively deny some of 
the requests received over that interface when the overload condition is detected. 
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queue_transactions 
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Mail Overload System SOLS 

Version 1.1 

Me! Bale/BT 

17 November 1998 

SYSTEM DIAGRAM 



maximum number of mail applications V K 
SYNONYM MAX.APP integer = 100; ^ 

r maximum number of user mailboxes 7 
SYNONYM MAX.MBOX integer = 1 000; 

/* null value for user mailboxes V ' 
SYNONYM MBOX_NULL integer = - 1 ; 

/' maximum number of service classes 7 
SYNONYM MAX_SERVICE_CLASS integer = 4. 

/• maximum length of an operation queue 7 
SYNONYM MAX_0PERAT10N_QUEUE integer = 10: 

/- — TIMER DURATIONS -—7 

SYNONYM tr_dur duration = 1; /' 1 second 7 
SYNONYM tr_duration integer = 1; T as tr_dur 7 



SYNTYPE MBOX_ADDRESS = mieger 

constants 0:MAX_MBOX 
ENDSYNTYPE MBOX_ADDRESS. 

SYNTYPE MBOX POINTER = integer 

constants M80X_NULL;MAX_MB0X 
ENDSYNTYPE MBOX_POINTER; 

SYNTYPE SERVICE CUVSS = integer 
constants 0;MAX_SEBVICE_CLASS 
ENDSYNTYPE SERVICE.CLASS; 

SYNTYPE OPERATION QUEUE.POINTER = integer 

constants 0:MAX_OPERATION_QUEUE 
ENDSYNTYPE OPERATION QUEUE POINTER; 
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NEWTYPE CAUSE 

literals T_over!oad, T unknown: 
ENDNEWTYFS CAUSE; 

NEWTYPE OPEHATiCN_STRUCT 
struct 
owner pid: 

mboxjd M30X ADDRESS: 
class SE?.VIC£_CLASS. 
info charsrnng; 
ENDNEWTYPE OPERATION.STRUCT. 

NEVVTYPE OPERATION QUEUE 

array(OPERATION_GU£UE_POINTER. OPERATtON_STnUCT) 

adding 

operators 

/' return true ii there are no more operations V 
is Jast : OPERATION.OUEUE •> boolean. 

/* add an operation to the queue 

- return true if queue is tuil 7 

add_op : CPERATION_QUEUE. OPERATION_STRUCT -> boolean 

r delete the current operation from the queue 

- return true if queue is empty */ 
deiete_op : OPERATION.QUEUE -> boolean; 

/' get the first operation stnjcture in the list '/ 
geljirst.op : 0P£RATI0N_QUEUE -> OP£RAT!ON_STRUCT; 

/' get the next operation structure in the list V 
get.next.op : OPERATION.QUEUE -> OPERATION.STRUCT; 

ENDNEWTYPE OPERATION QUEUE; 



Figure 3c 
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NEWTYFE ,V1B0X_STRUCT ^ 
Struct 

class SERVICE CLASS: 
mbox_id MBOX_ADDRESS, 
pfocessjd pid; 
opener id pid. 

openerIset_class SERVICE CLASS, 
nextjnjist MBOX_POINT£R, 
queue boolean: 

op.queue OPERATION_GUEUE. 
eNDNE"WTYPE MBOX.STRUCT; 

NEWTYPEMBOX LIST 

array(MBOX_ADORESS. MBOX^STRUCT) 
adding 

operators 

/■ return true if there are no more mailboxes '/ 
isjast : MBOX.LIST -> boolean; 

/' add an open mailbox struct to the list 

- return true if list is full V 

add.nabox : MBOX.LIST, MBOX_STRUCT •> boolean, 

/' update an open mailbox struct to the list 

- return true if list \s full V 

update_mbox : MEOX_LIST. MBOX.STRUCT -> boolean; 

/• delete an open mailbox struct from the list V 
de!ete_nnbox : MBOX_LIST, MBOX_STRUCT -> boolean; 

/• get the first open mailbox structure in the list V 
get Jirst.mbox : MBOX_LIST -> MBOX_STRUCT; 

/• get the next open mailbox structure in the list V 
gel.next.mbox : MBOX.LIST •> MBOX_STRUCT; 

/' get a specific open mailbox structure from the list V 
get_mbox : MBOX LIST. f^BOX.ADDRESS -> MBOX_STRUCT. 
ENDNEVmPE MBOX.UST; 

NEWTYPE RATE:.STRUCT 
struct 

min_rate integer; 

max_rate integer; 
ENDNEWTVPE RATE_STRUCT. 

NEWTYPE RATE.ARRAY 

array(SERVICE CLASS. RATE STRUCT) 
ENDNEVmPE RA'TE.ARRAY; 
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SIGNAL r SIGNALS for routes 1 7 

user mailbox open(MeOX ADDRESS). 

user_mailbox close(M60X_AODRESS). 

user mailbox opened(MBOX ADDRESS). 

user_mailbax_dosed(M30X_ADORESS). 

user_maiIbox_requestfMBOX_ADDRESS.chafString). 

user~mailbcx_notificaticn(MBOX_AODRESS.charstrir.q 

usermailbox_open_cIenied(MBdX_ADDRE3S, CAUSE 

inaiLapplicahon_overload_detected. 

maiLappl(canon_overload_ceased; 



SIGNAL /• SIGNALS for route 2 "/ 

UM open(pid. MBOX_A0DRESS). 

UMlclose(pid, MEOX_ADDRESS), 

UM_opened(MBOX_ADDRESS). 

UM open_denied(MBOX ADDRESS.CAUSE). 

UMlcIosed(MBOX_ADDRESS). 

UM_request(OP£RAT]ON STRUCT). 

UM noti{ication(OPERATION_STRUCT), 

impose_UM load_controI(pfd.SERVICE_CLASS). 

queue UM requests(MEOX ADDRESS). 

resume UM requests(MBOX_ADORESS); 



SIGNAL /• — SIGNALS for route 3 V 

queue_noti(tcations, 
resume_notifications, 
stop mailbox. 

request(OPERATION STRUCT). 
notrficatton(OP£RATlON_STRUCT); 

SIGNAL r — SIGNALS for route 4 - — V 
transaction rate(inteGer), 
set_UM_ciass_bar(SERVICE_CLASS); 



SIGNAL r--- SIGNALS for route 5 - — V 
UM s€rvice_class query{r>/BOX_ADDRESS). 
UM'service class resuft(MBOX_ADDRESS.SERVlCE_CLASS) 



SIGNAL /"-— SIGNALS tnternal to User.Mailbox ■ 
event(OPERATION_STRUCT); 



V 



SiGNALUST S!isLl_cut = 
user_maiibox_opened. 
user_maiibox_open_depied. 
user_m»ailbox_closed 
user mailbox notification. 



SIGNALUST S!isl_l_in = 

user_mailbox_cpen, 

user_mailbox_ciose. 

user_maiIbox_request, 

maiLapplication_overload_de!ected 

maiLappiication_overload_ceased: 

SIGNALLIST SI(St_2_out = 

UM_opened, 

UM_open_denied. 

UM_ctosed, 

UM_not(fication, 

queue_UM_requests. 

resume_U M_requests: 

SIGNALLIST Slist_2_in = 
UM_open, 
UM_close. 
UM_request, 

impose^UMJoad.control; 

SIGNALLIST Slist_3_out = 
notification; 

SIGNALLIST SIist_3jn = 

queue_notificalions. 

resume_notiftcations, 

request. 

stop_mailbox; 

SIGNALLIST Slist_4_out = 
sel_UM_class_bar; 

SIGNALLIST Slist_4jn = 
;transaction_rate; 

SIGNALUST Slist.S.out = 
UM^service.class.query; 

SIGNALLIST SIist_5jn = 
UM service_class_r9sult: 
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1 



MAIL SYSTEM ADMIN 



[(Slist_5_out)] 



[(S;rst_5_in)] 



5(5) 



rrsiist_i_out)j 
Application_User3 

[(Slistjjn)] 



matLapplication_block 



[(S!ist_2_out)] 



MAIL_SYSTEM API 



[(S!ist_2,m)] 



mail_system„block 
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Block maiLapplication_block 
r "''^ 

1 

1 > 


1(1) 

1 (bilSt_l _OUI) 

APPLICATION.USERS 
SI 

[(SIist_ljn)j 


/ \ 

maiLapplication(0,MAX_APP) 

\ / 




[(Slist_2,oul)] 

MAIL_SYSTEM_AP1 
S2 

[(Slist_2Jn)j 
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1(3) 



riSIGNA'LSEt 7» 

'user_maitbox_notificatton, 

luser_mai[box_oDen. 

luser_mailbo)(_close, 

[user_mailbox_request. 

iUM_opened, 

!UM open_deniec!. 

iUMlclosed. 
I jUM_noMication, 
■ iqueue_UM_requests. 

I resume _UM_requests; 



O 



alive 



\ user_mailit)ox 
/ (mboxjd) 



user_rTiatll)Ox_ 
close 
(mbox_id1 



UM open \ UM close \ 
(SELF, mboptiid} (SELF, mbo/id) 

~~iz — 



CD (ID 



Variables —-7 

DCL mboxjd MBOX ADDRESS; 

DCL mboxes MBOX llST: 

DCL mbox M80X.STRUCT: 

DCL cause_ref CAUSE; 

DCL class SERVICE.CLASS; 

DCL info charstring; 

DCL fuHboolean; 

DCL empty boolean; 

DCL op.slrud OPERATION^STRUCT; 



true 



>user_maii )ox 
..request 
(mboxjd 



nfoj 



(nibo 



mcox - 
get_fnbox 
xes.mbox_ 



(p struct'owncr 
^ ":=SELF 



o;}_struct!mbox 
: mbGx_id 



op_struct!infc 
:= info 



full ;= add_op 
(rfibox!op_queup, 
op_struct) 




UM_^eques^ 
(op^struct) 



GDC 



Figure 3h 
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fSfGNALSTi; 

I ^ 

'user mailbox! 



UM_notifi 
{op^struct' 



Of J 



tcartior 



mboxjd '= 
struct!mbox. 



info := 
op_struct!info 



user_maill)ox, 
_notHicali£^n 
fmboxjd. 



nfo) 



CD 



alive 



UIVl_openi 
(mboxjd} 



UM_clcsed/ 
(mboxjd)\^ . 



UM_opefi_y 
_denied 

fmbox.'c.c^s&^'er) 



Tiboxlmboxjc 
: rrbox id 



mbox = 
ge!_mbox 
(njboxes.mbox. 



mbox'queue 
false 



<user_maill)o;( 
_operv_deT 
[mbcxjd. c 



empty = 
delete_maox 
< mboxes.nnbo)j ) 



f ill := add_mbdx 
(mboxes.mbox) 



led 

caL!se_ref) 



usar^m 
_closed 
rmboxid] 



aill>ox_ 



user_mail|)ox, 
_opened 
{mbox_td) 
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i Process mail_application 



3(3) 



rsrGiNAis'E^ 

'user mailbox' 



r 



maii_aopti 
_overload 
.detected 



MAX 



class =. 
ScRVlCE CLASS 



lead centra 
(SELF, ctayi 



ative 



>rnaiLaDpi!Carion_ 
.overload! 
,c3ased | 



class 0 



(ribcx 



fmpose_Ui^ 


load 


ccntrdj 


fSELF 


c!a^ 







CZJ 



true 



CD 




op_struct := 
getjirst_pp 
(fftbox'cp_queu 



UM^requesl 
(op^truct) 



empty := 
delete.op 
(rttbQX^op_Queu 



true 




op_stnjct -= 
get„next_op 
(r ibox'op^queu 
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[(Slist_2_out)] 



1(1) ! 



MAIL_SYSTEM_API 
S2 



[(S;ist_2_in)] 



MAIL_SYSTEM_ADMIN 



[(Slist.S.out)] S5 [(Slist_5_in)] 



access_controller(1,1) 





[(Slist_4_out)] 
S4 




"(SItst.3_out)] 




[(Siist.4jn)] 






/ \ 

overload.coniroller (1,1) 




S3 


\ 


/ 












[(SIisl_3Jn)] 



user_mailbox (0,MAX_MBOX) 
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Process access_controller 



1(5) 



rsFGNALScf" |v 
I 

'UM open, 

lUMlcIose, 

lUM_request, 

;impose_UMJoad_contfoi, 

motification. 

!set_UM_ctass_bar, 

I U(vr_sery/ice_c!ass_result; 




— Variables 7 

DCLUM.class barSERVJCE CLASS =0: 
DCL current class_bar SERVICE CLASS ;= 0, 
DCL class SERVIC£_CLASS .= o7 
OCL mboxjd MBOX.AODRESS: 
OCLmboxes MBOX.LIST; 
DCL mbox M80X_STRUCT; 
DCL full boolean = false: 
DCL empty boolean := false: 
OCL tr_counter integer .= 0; 
DCLMApid; 
DCLUft/pid; 

OCL op queue OPERATION_QUEUE. 
OCL op struct OPERATION_STRUCT. 



/' Transaction rale tirner - 

TIMER tr jimer: 



queue_transactions 



resume 



ransactions 
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Process access_controiler 

'UM_open. ! 



2(5) 



o 



UM_clcse 
(MA. moo tjd) 



tr^counter 
tr "counter • 1 



mbox := 
get.mbox 
(n tboxes.mbox. 



d) 



UM := 
- mbox 
'process jd 



stop_maiib 
to UM 



3^ 



empty := 
delete^mbox 
(mboxes.mbox) 



< 



UM.close J 
(mboxjd) 
to MA 







set 

(NCW.lr.dur, 
trjimerl 


N 





ahve 



UM_open 
(MA. mbo 



Jd) 



tr_counter := 
tf counter + 1 



:;et_UM_clas 
(class) 



true 



user^mailbox 



Tibox!mbox_ic 
= mboxjd 



mboxfqueue 
:= lalse 



f jill *= add_nnbci( 
imboxes,mbox) 



UM_open(ic 
(mboxjd) 
to MA 




mbox 
'processjd 
:OFFSPRiN$ 



UM_open. .denied 
(mbox id. T_overioad) 
to MA 



mbox 
lopenerjd 
:= MA 



mboxiclass 
:= class 



mbox! 



[Default to zero 
o|)ener_set_cla^-jeven though the 
jMA may have set 
la different load 
I level class 
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Process access controller 



■3(5) 1 



I \ 
I < 
iUM_open, ' 



set,UM_cbis_bar 
(UM_class\barj 




current ctass_b 
■4 UM class 



;aise 



lass'jmes that 
--(the values are 
mot equal, and 
Ichange by T 



ctirrent_class_bar 
-T UM_class_b;ir 



ur 



1 ^ueue_re 
(op aud je.current 
SELF) 



qii€;>ts 



resL 
{c| 



c !iss_bar. 



mejransacqpns 
rrenl^class. 
: mboxes) 



har. 



Figure 3n 



4 



-^1-1-i99S:; 



EP983d967;9.3 



DRAW 



Process access.controller 

'UM_open. J 



UM_requdst 
(op.struct 



mbox jd := 
op_slr'jci! 
mbox id 



mbox •= 
geLmoox 
(n) boxes. mbox. 



false 




d) 



true 



iboxlqueuj 



UM:= 
niboxiprocess. 



request 
(op_struct) 
toUW 









Dp_struct!clas: 
mboxiclass 








fuit := add^op 
(op_queue, 

Op.StOfCt) 







tr^counter := 
tr "counter + 1 



ncliiicatioo/ 
(op_5iruciK 



MA := j 
op.struct' 
owner 



UM_notii!(}atton 
(cp_struct 
to' MA 



tr.counter 
tr counter + 1 



4(5) 



trjimer 




tr counter := C 



set 

(NOW-^tr.dur, 
tr_timerl 



] C 



•Pfinted:24-b2-2000', 



Figure 3o 



17 



25-11-1998^ 



;EP98309679,3 



DRAW 



Process access^controller 



'UM_open. 
lUM_close, 
lUM_[*equest. 

])mpose_UMJoad,controI. 
inotification. 
lset_UM_class_bar. 
[UMlservice.class.resull; 



5(5) 



alive 



impose. 
Joad_co 
fMA. das^) 



UV1_ 
rtrol 



mbox = 
get_first_mbO) 
(mhoxes^ 



has 'ihe control 
been imposed atf- 
this level? 



IS thts mailbox! 
affected ? <" 




false 



true 



true 



UM := 
njbox!process_d 



do not request the | 





■ cu 


queue requests j J 






true [ 










op 




queue 


_not^>^atio^s 






to UM 








false 



resume_nor<ications 
to UM 



mbox! 
o{)ener_set_ 
:='class 



cla (s 



ful 



updatej 
(mboxes.mboxf 



mt ox 



true 




mbox ;= 
<iel_next_mbo; 
(mboxes) 



Figure 3p 



25-1 i-1.998. €P983q9679.3; DRAW^^ 



Procedure geLUM^class 

IN/OUT class SERVICE CLASS. 
IN mbox Id MBOX ADDHESS." 



1(1) ! 



UM^sefv; 
(mbox. 



erviceScI, 

jd)y 



!ass_query 



waiting 
1 



UM_servicfficIass_result 
(mboxJd,Class) 




Figure 3q 



Printed:24^2-26Ga. 



19* 



25-11-1.998.. 



EP98309679.3* 



-DRAW 



' Procedure queuejransactions 

IN current class bar SERVICE_CLAS3:^, 
IN mboxes MBOX_LIST. ; 



mbox = 
3etJirst_mbo) 
f mboxes) 



r Variables 7 

DCL mbox MBOX.STRUC 
OCL MA pid. 
DCL UM ptd: 



1^1 




1(1) ! 



mbox'.queue 
:= true 




queue_nctm^ 

to UM y 



.ations 




true 



mbox := 
^et_next_rnbojc 
fmboxes) 
1 




Figure 3r 



=525-11^1996: 



ER98309679i ^^W^.: 



Procedure resumejransactions 



•-PAR *^ 
IN curreni class.bar SERVICE _CLASi^, 
IN mboxes MBOX_UST; ; 



, Variables V 

DCL mbox MBOX.STRUC 
OCL MA pid: 
DCL UM p!d: 



mbox := 
39tJirst_mbO) 
(mboxes) 




< 



resume requesjs 
to MA 



mboxiqueue 
:= false 




false 



[cations 



1(1) 



true 



mbox := 

(|et_next_mbo : 

(mboxes) 
_ 




f Primed:24-02-20b0. 



Figure 3 s 



•25-11-1998 



EP98309.679.3. DRAW 



Procedure set Jhresholds 



1(1) 



f;FPAR l\ 
IN/OUT levels RAT£_ARRArr, 
IN/OUT minjevel integer. | 
IN/OUT max_level integer; i 



leve!s{0) 
!min rate 0 



levels{l) 
min rate := ec i 



levels(2) 
iMtn rale := 18 



levets(3) 
'tnin rate := 28 



ievels{0) 
'f)iax_rate := 1dO 



leve!s(l)" 
!(hax_rate := 260 



levels(2) 
fitnax rate := 3dO 



levels(3) 
'ihax rate .= 4d0 



minjevei := 
levels(O) 
liTiin rate 



max. level := 
levels(O) 
(max rate 




Figure 3v 



25-11 -.t'998"- 



DRAW 



Process user_mailbox 



[ySIGNALSEf" 

iqueue.notifications, 
iresume_notifications, 
[request. 
! event, 

stop_mailbox; 



^ alive ^ 



\queue_no 






queue 


.= true 




I _ "equest 



GZJ 



tfications 



Jqueue up any 
[notifications 
) 



true 



^^r esume_nt)tificat(ons 



(Stop queuing 
queue := false] — ]nottfications. 

|and send those 
•stored in the 
iqueue 




/• — Vanables — V ^ 

DCL queue boolean := false; 

DCL op_struct OPERATION_STRUCT; 

DCL op.queue OPERATION.QUEUE; 

DCL full boolean := false; 

DCL empty boolean := false; 



op_struct ;= 

?ietJirst_op 
op queue) 



event 
(Gp_struct) 
to SELF 



empty := 
deIete_op 
(op_queue) 



true 




fatss 



op_struct 
get_next_op 
(op,queue) 



Figure 3w 



.Printed:24-02-200Q-^ 



.'25-11-1998. 



:EP98309679.$ P.BAW ;. 



Process user_maiIbox 
rsrcNAlsT!:. 



2(2) 



;queue_no]ific{ 



alive 



\. request 
y^(op_struct 



event 
(op^struct 



stop_main)0)c 



p(!fform_feque:;l 
(op.struct) 



Iperform the 
---[requested 
|operation, anc 
Istore the pid 
|of the 

] requesting MA 



true 




false 



queue 



X 



tuli *= add.op 
(op_queue, 
op .struct) 



1 



notificatiori 
(op.struct 



Printed:24-0?r.2000.: 



Figure 3x 



i25-1 M998; :'EP98309679,3. ©BAW 



Procedure perform_request 

— - — \ 

;;FPAR [N op.struct OPERATlON_STRUCt:*[ 
I I 



1(1) 



c 




) 






op_struct'info 
.= 'done' 




IpeSorm the 
--[requested 
joperation 



Prjnted^24-b2\2O0f 



Figure 3y 



27 



25-1 M 998 



EP98309679.3 



DRAW 



O) 



^ £ "c 

5 = s 



.09 



^ o 

1^ y fc- E 

iij y > s 

a: ,-3 c " 

Co 



UJ3)SAS 



i3q)0 























1 








CO 






c 












P 



CN 




A 

U 



is 

? S 



P 



<-> -a 
*> ■> IZ 
^ o ^ 



t 



A 



C5 51 



^ p 

Co 



S iJJOJ]B[d 
ApiAOjd 301AJ3S 








CO 






C 


CO 




O 


ELF 


mail 


llcati 


cc 




dd 







Co 



E I 
So ^ I 



Co 











r o 


cliv 


ce 


« 
c 


i 


ilera 


> 


respc 















,y 


Co 






c 
















5: 







A 



Co <u 



.§1 



^ 5 



> 
o 
u 

C/3 





This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 



□ OTHER: 



IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 



